「您賣(買)的是一個"package"?還是"solution"?」這跟專案成本跟時程的考量是緊密連結的，也跟專案進行方式與風險承擔更有著天壤之別的差異。
上週約了兩位經研所同學在桂林路的家樂福吃個飯，並聊一聊互相的近況。以大家現在工作的年資，都大約是中低階主管的資歷了，最是勞心勞力的一群，每天面對著繁瑣的工作，總會讓人感到心力憔悴。
其中一位同學現任職於xx壽險的放款科長，他知道我在IT軟體產業，他問我一個問題：「一年計息天數基礎(Days in year)為什麼系統不可以提供給使用者參數的型態，讓使用者自行決定，為什麼一定是360？印度的顧問竟敢要求我們修改作業規則去適應他們的系統，這可不是內部的作業規則，而是金管會的規定，放款的計息天數基礎是365。」
我想很多人的第一反應就是那個系統太爛，設計不良！但我不是如此思考！因為該外商的產品可是已經行銷好幾國，問題真正癥結點是出在當初合約的規範！當初xx壽險招標之時他所設定的想法：「他要買的是一個"package"?還是"solution"?」若是xx壽險所要的僅是一個套裝軟體，而且合約或Request for Proposal(建議書徵求書上)未明載計息天數基礎的需求。沒錯，就如那位印度顧問所言：「這是客戶的問題，要求客戶自己處理。」但如果xx壽險當初所要的是一個解決方案，而且合約已有載明系統必須能提供計息天數基礎的參數設定，那這問題就回歸到廠商的身上。
一般人或許以為這個修改很單純，不過改一下數字嗎？但在金融應用軟體上，基層參數與架構的修改可是牽一髮動全身喔！有些金融應用軟體是每日計息，有些是每月計息；計息天數基礎參數有的是所有產品別一體適用，有的是根據產品類別，有的是根據每一契約。這還牽涉到提前還款，解約，逾期…等不同的繳款狀態；而繳款的方式不同－現金臨櫃、便利商店繳款、支票繳納…－也會造成影響。因此這可不是改一個數字就好了的簡單想法。
個人近來忙於北部一家地方性金融機構的建議案，此次我們所提供的是一個解決方案"solution"。本案中我們除了包括一部份系統外，更擔任了系統整合商的角色。在合作的五家廠商中有的是提供套裝元件，有的是需要提供客製化修改，因此專案管理的責任跟風險就在系統整合商的身上。
日前聽說：「xx銀行已簽約更換現有的Unisys銀行核心系統為Temenos系統。全程以英文為溝通的語言，而且以現有Temenos系統的功能為交付的功能，不進行修改。」若真得如此！則整體風險將在客戶的身上，廠商其實就只有安裝跟協助使用。
從以上的例子，我的客戶要的是一個"solution"；而xx銀行要的僅是一個"package"。這其中的價格差異可是很大的！屆時xx銀行在無法更改"package"下，勢必要修正一些作業規則，或者自行在"package"外面加以包裝，以符合實際的需求。
個人先前也曾親身參與過一個國際知名的應用產品廠商的專案。原國外母公司的規定是他們僅販售"package"和協助進行參數設定。但因為台灣的競爭激烈，業務們當成"solution"去賣，以致後續可能必須以非IT的能力去結案。這個就是一個非常大的盲點：「您賣(買)的是一個"package"?還是"solution"?」這跟專案成本跟時程的考量是緊密連結的，也跟專案進行方式與風險承擔更有著天壤之別的差異。
我想你說Package指的是Product吧. Package指的可以是Product也可以是Solution, Package只是一個"單位", 而您舉的一年計息天數基礎(Days in year)例子, 印度顧問會如此無理, 基本上是因為這個問題牽涉到核心系統的修正, 必須經過繁複的修改,測試, 與計畫, 對我來說, 這問題確是一個嚴重的bug, 但是這個與product vs solution無關啊. 我設計過一個很複雜的合約系統, 我的原則是, "口語化"所有可提供的計算參數,讓使用者依權限判斷. 至於您提供的Temenos系統案例, 我以前上企業文化對IT系統的交互影響課時, 有許多這樣的案例, 廠商依然提供的是一個solution, 對客戶來說是一種選擇, 選擇一個最適合企業文化或調整企業文化最小的solution, 對經營管理階層來說, 修正作業流程以避免修改IT系統可能是最低成本的solution. 至於product和solution最大的差別不在於系統是否能修改, 而是在於solution提供給客戶不同的選擇. Red Pill? Bule Pill? 是soultion, 但是Pill只是product.
My dear friend:
也許小弟的措詞不當，package跟solution都是product或service！我的意思在於：「實際滿足最後使用者的實際需要的中間過程，是由誰來思考、解決跟建置！」
至於計息天數基礎(Days in year)我想這不能算是bug啦！比如有些金融業務法規或慣例如歐規是360,日規是365,美規有些金融商品是360有些是365。比如你在日本開戶日本計息基礎是365，但在同一銀行的OBU開就是360。
如果程式無法讓使用者設定重要參數, 如天數, 這就是邏輯上的Bug. 而且是最嚴重的bug, 因為會成為日後客戶和軟體公司本身高昂的成本.
至於英文方面, 我想很多人都有的誤解吧,我從來不知道package在台灣的意義指的是套裝軟體, 其實英文應該是off-the-shelf software. 這也是為什麼我會提出不一樣的看法. 請見諒, 至於antijava所說, 我原本也看不懂, 不過, 我曾在那家德國公司上班, 也知道一些"改造"過程, 很難過, 很多台灣的製造業還是高級代工業, 但是那與off-the-shelf和solution無關, 應該是說在企業文化與IT的交互影響之下, 只有改造國外的軟體吧.
Sorry!
這是我的錯啦!因為我是土芒果，又是中途轉IT，有些TERM就是這樣道聽塗說學來的！
其實這也發生過好幾次了！不過這次我又學到一個名詞，感恩！
甲方總想用package的價格，買到solution的價值
乙方總想用package的東東，賣到solution的價值
結果常常是
package被一直改一直改改成solution
(最經典的應該是多年前
挾「德國製造、精粹流程」來台銷售的ERP系統
進了竹科
被好好地「改造」了一頓)
印象中
似乎越「小」的資訊系統越能當成package(例：Office、套裝會計系統)
越「大」的資訊系統越不可能當package賣(例：ERP)
HaHa!
還是antijava瞭解我的想法，第一次潑文有那麼多人討論ㄚ。
不敢不敢
只要提到ERP
albertachen大大(<--ERP專家)就比較有興趣了...^-^
package 不是 為了 solution 嗎 ??
甲方總想用 package 的價格，買到 solution 的價值 ??
package 可能比 solution 更貴或便宜都有可能
package 代表更多的參數是外宣告
package 代表應用更多 SOA 功能 更容加功能
package 代表應用更多 MDA 功能 更容改功能
只是甲方的偷懶不將 solution 的細部規格詳述
詳述到驗收標準
詳述到可以舉辨程式競賽
買 package 也該訂定 驗收標準
對金融的核心系統與主要應用系統來說，要把規格詳述清楚那可能要寫好幾本喔！
個人先前也曾親身參與過一個國際知名的應用產品廠商的專案。原國外母公司的規定是他們僅販售"package"和協助進行參數設定。????
行參數設定????
有哪些是常數
有哪些是參數
你都不知道你就買了
My dear friend:
因為那套系統還蠻複雜的，他的參數內還可下類似SQL DML的語法，他的使用手冊好大一本！
我最近也碰到這樣的情況...
我們公司所提供給某客戶一套會計用來統計事務機印量的軟體
這玩意就很單純的是套裝的軟體
但到了客戶手上...
一天到晚跟我抱怨某個設定為什麼要那樣做
怎樣怎樣做不是比較好嗎...
老是跟我說你們修改一下應該很簡單吧
只是一個小功能啊!!
修改軟體最好那麼簡單啦
權限又不在我身上 ="=
軟體是外國寫的套裝軟體耶
又不是為你們量身訂做的...
某些功能對你們很方便沒錯呀
但這軟體又不是只做來賣給你的...
總之老是有小抱怨冒出來就是了
還很愛拿其他廠商的東西來做比較
"某某廠商他們的東西都ok呀 我想你們也應該能做到才對吧
多互相學習才會有成長啊"
這種fu一整個很討厭...
最後就會變成軟體沒辦法達成的部份要我們提供其他的替代方案給他
真的就是出張嘴抱怨就好
我們就要拼死拼活絞盡腦汁想辦法去解決...
根本不能跟客戶說"不可能"
"不可能"都要改口說我們會想看看有沒有辦法解決....
在台灣...套裝的東西都要變成solution了...
根本是惡性競爭的結果...
根本是惡性競爭的結果...說得好啊.
但是, 我覺得您提的案例中, 使用者的要求是對的, 對於軟體公司而言, 這些使用者提的小功能可能會是日後廠商市場競爭的決勝武器.
但這種要求只能當作下次改版的建議了
不可能及時幫客戶修改啊
每次客戶要求沒有的某功能時
就覺得很無奈...
夾在客戶和軟體原廠之間
我也知道有些功能很方便呀
但台灣部分根本沒有修改軟體的權利啊...
開發小組是外國的呀 =口="
有些外國人在寫軟體就是比較嚴謹呀...
嘆
是啊, 你說的沒錯, 我也曾經很無奈, 也嘆過, 但是為何要採用? 我有一個小故事分享:
某上市公司MIS主管告訴我, 幾年前, 他們採用某國外的軟體, 花了數千萬數年後宣告失敗, 他還告訴我, 公司的政策是不會用小公司的軟體的, 理由很簡單, 用國際大廠的軟體失敗了不是自己的責任... 反觀德國, SAP當初只是一家小公司, 但是德國企業挺, 挺出了國際大軟體公司, 再看南非, k2當初也是由一個案子磨出來的, 可是台灣呢? 其實大陸也一樣. 也許說國產軟體不夠格, 其實許多的新興軟體公司也不錯, 但是如何競爭? 在小案子裏掙扎求生?MIS要挺啊.
是ㄚ！
我也深深感到國內的顧戶一味的媚外，買回來的東西，沒有source code，全部的一切都綁的死死的！其實系統是錢砸出來的。確實國外有些很好的應用軟體或者軟體開發的文化，值得我們學習。但是臺灣也需要一個軟體可以發展的空間，一個案子下來，硬體和系統軟體拿去五分之三到五分之四，後續維護一般公家的只有5%還要用應用軟體的維護費去補硬體的維護費。聽說(只是聽說)SAP的每年維護費有22%，唉....
在台灣...套裝的東西都要變成solution了...
根本是惡性競爭的結果... ?????
在地球...套裝的東西都應該變成solution了...
無法該變成solution根本是
未開放源碼 + 沒有技術轉移
廠商自大故步自封行為的惡性結果...
比較精確的說法是 您進行的是一個"客制專案"?還是要購買"產品"? 我們常遇到的是要買這兩者的混合體,於是;RD常常思考一個問題,如何讓產品的延伸性可以做到像客製化這麼靈活,或是我只想滿足80% 的市場需求
iThome鐵人賽
看影片追技術